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ABSTRACT 

A compiler without a runtime library is like a can of food without a can 
opener: you may have paid for your meal but you can’t eat anything. This 
memorandum describes a set of library routines provided for the C language on 
UNIX, GCOS and OS/370 to improve portability of C programs between these 
systems. With these routines, programs to do sequential input and output can 
be written in a relatively machine-independent way. 

C was designed and implemented on the UNIX PDP-11 system by 
Dennis Ritchie; the compiler for GCOS was written by Steve Johnson, and 
that for OS/370 by Tom Peterson. The language is suitable for many non¬ 
numeric programming problems and the I/O routines, patterned after those on 
UNIX, provide general character stream facilities. 

Auxiliary routines useful to C programmers are also described: these in¬ 
clude the C compiling and loading commands for GCOS and OS/370. Various 
other useful routines, such as the C debugger for GCOS, are also described. 
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Barres. 
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MEMORANDUM FOR FILE 


1. INTRODUCTION 

The C language [1] now exists on three operating systems. A set of library routines com¬ 
mon to pop 11 UNIX, Honeywell 6000 gcos, and IBM 370 OS has been provided to improve pro¬ 
gram portability. This memorandum describes the routines on the different systems. It is the 
sole current reference to libraries for GCOS and os. and supplements the UNIX programmer’s 
manual. A variety of programming aids available for C users, such as measurement and debug¬ 
ging aids, are also described. 

The programs defined here were chosen to follow the standard routines available on 
UNIX, with alterations to improve transferability to other computer systems. It is expected that 
future C implementations will try to support the basic library outlined in this document. It 
provides character stream input and output on multiple files; simple accessing of files by name; 
and some elementary formatting and translating routines. The remainder of this memorandum 
lists the portable and non-portable library routines and explains some of the programming aids 
available. Appendix 1 provides an index to the currently available routines. ^ 

We will refer to several subroutine libraries in the following sections. Each host comput¬ 
er provides a non-portable system library, described in the appropriate system reference manuals 
[2,3,4], To simplify the task of writing portable software, the portable C library described here 
permits basic input and output operations on multiple files to be performed without using 
system-dependent calls. This library will be provided, at least as an alternative, in each C run¬ 
time environment. Additional features are offered in specific environments; when these 
routines are available in several places an effort is made to define them compatibly. These sup¬ 
plementary capabilities- may be provided in future C systems, although many are only of in¬ 
terest on a particular operating system, and some routines may be difficult to implement in fu¬ 
ture run-time environments. 

In general, statements in this memo apply to all of the systems where C is implemented. 
When this is not true, a three-column format is used, in which the left column is applicable to 
UNIX, the middle column to GCOS and the right column to os/370. 

UNIX GCOS OS/370 

Two simple subroutines will be adequate for many users. Getchar () returns a character 
from the standard input, usually the teletype; and putchar (c) writes a character on the standard 
output, also usually the teletype. Putchar returns as its value the character written. By C con¬ 
vention, ‘\0’ indicates end of file or end of string. Thus the program 


* This memorandum is a revision and extension of MM74-I274-1, “The GCOS C Library", by M. F. Lesk and B. A 
Barres. 
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main () 

I 

while (putchar(getchar()) /= \0’); 

} 


will echo lines typed at it. 

To compile and run this program, it should first be entered with the local editor into a file 
named 

prog.c prog.c prog.text 

The command dialog to compile and execute would appear as follows: 

% cc prog.c -lp system ? ./cc prog.c h= ready 

% a.out system ? go .program ccg prog 

The I/O routines in the C library fall into several classes. Files are addressed through in¬ 
termediate numbers called file-descriptors which are described in section 2. Several default file- 
descriptors are provided by the system; other aspects of the system environment are explained 
in section 3. 

Basic character-stream input and output involves the reading or writing of files considered 
as streams of characters. The C library includes facilities for this, discussed in section 4. 
Higher-level character stream operations permit translation of internal binary representations 
of numbers to and from character representations, and formatting or unpacking of character 
data. These operations are performed with the subprograms in section 5. Binary input and 
output routines permit data transmission without the cost of translation to or from readable 
ASCII character representations. Such data transmission should only be directed to files or 
tapes, and not to printers or terminals. As is usual with such routines, the only simple guaran¬ 
tee that can be made to the programmer seeking portability is that data written by a particular 
sequence of binary writes, if read by the exactly matching sequence of binary reads, will re¬ 
store the previous contents of memory. Other reads or writes have system-dependent effects. 
See section 6 for a discussion of binary input and output. 

Section 7 describes some further routines in the portable library. These include a storage 
allocator and some other control and conversion functions. Non-portable routines are 
described in sections 8U, 8G and 81. The commands to compile a C program on UNIX, GCOS 
and IBM TSO are described in sections 9U, 9G and 91 respectively. Some useful utilities and 
support software are described in sections 10 and 11. Finally, when you get into trouble with 
all of this, the C debugging facilities are described in section 12. 

2. FILE DESCRIPTORS 

Except for the standard input and output files, all files must be explicitly opened before 
any I/O is performed on them. When files are opened for writing, they are created if not al¬ 
ready present. They must be closed when finished, although the normal cexit routine will take 
care of that. When opened a disc file or device is associated with a file descriptor, an integer 
between 0 and 9. This file descriptor is used for further I/O to the file. 

Initially you are given three file descriptors by the system: 0, 1, and 2. File 0 is the stan¬ 
dard input; it is normally the teletype in time-sharing or input data cards in batch. File 1 is 
the standard output; it is normally the teletype in time-sharing or the line printer in batch. 
File 2 is the error file; it is an output file, normally the same as file 1, except that when file 1 is 
diverted via a command line ’>’ operator, file 2 remains attached to the original destination, 
usually the terminal. It is used for error message output. These popular UNIX conventions are 
considered part of the C library specification. By closing 0 or 1, the default input or output 
may be re-directed; this can also be done on the command line by >file for output or <file for 
input. 
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Thus, suppose the program above to be stored in executable form on the file 
P r0 8 prog.h cllm.load(prog) 

If it is invoked by the command line 

prog <data /prog.h <data call cllm.load(prog) 'prog 

<data' 

the file data is listed on the teletype. If invoked by 

prog >newdata /prog.h >newdata call cllm.load(prog) ’prog 

> newdata ’ 

lines typed at the terminal are written into the file newdata; and if invoked by 

prog < old > new /prog.h < old > new call cllm.load(prog) ’prog 

<old >new' 

the contents of the file old are copied into the file new; in the last two examples, the files new¬ 
data and new will be created if not present. 

The running program, of course, has access to the command line via the main program 
arguments, except for “>file” or “<file” arguments, which are handled by the start-up 
routine. If you intend to provide arguments on the command line, your main program should 
begin 

main (argc, argv) 
int argc; char *argv[]; 

where argc will be set to the number of command line arguments, and argv will be a vector of 
pointers to the successive arguments as character strings; note that argvfO] normally gives the 
command name by which the program was invoked. 


In GCOS batch the command 
line is read from filecode 
CZ; it will be supplied for 
any batch job submitted by 
the ,/sh driver. This 
“pseudo-shell” is described 
in section 10. 


Note that on OS/370 the 
“command line” is the 
string normally called the 
PARM string in IBM termi¬ 
nology. 


Associated with the portable library are two external integers, named cin and cout. These 
are respectively the numbers of the standard input unit and standard output unit. Initially 0 
and 1 are used, but you may redefine them at any time. These cells are used by the routines 
getchar, putchar, gets, and puts to select their 1-0 unit number. 


3. THE C ENVIRONMENT 

In general, C requires some modifications to the standard system runtime environment to 
support recursion and call-by-value. An effort is made to minimize the effect of this on pro¬ 
grammers accustomed to the standard system environments, as well as providing the portable 
facilities needed. The language is almost exactly the same on all machines, except for essential 
machine differences such as word length and number of characters per word. 
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ascii character code is used. ascii code is used. Charac- EBCDIC character code is 

Characters range from -128 ters range from 0 to +511 used. Characters range 

to +127 in numeric value, in numeric value, there is from 0 to+255, no sign ex- 

there is sign extension no sign extension on char- tension, and logical right 

when characters are as- acter to integer conversion, shifts. The “first” character 

signed to integers, and right and right shifts are logical. in a word is stored in the 

shifts are arithmetic. The The “first” character in a leftmost . quarter word, 

“first” character in a word is word is stored in the left- Floating point, and the 

stored in the right half most quarter word. operators =*, =/, =%, 

word. =■>>, and =<< are not 

yet implemented. 

More serious problems of compatibility are caused by the loaders on the different operating 
systems. 

External names may be External names must be External names are one- 

upper and lower case, up to unique in the first six char- case, but may be up to eight 

seven characters long. acters of a one-case alpha- characters long. There may 

There may be multiple bet. There may be only one be only one external 

external definitions (unini- external definition of a definition of a given name; 

tialized) of the same name. given name; all other uses all other uses must be refer- 

must be references. ences. 

The C alphabet for identifier names includes the upper and lower case letters, the digits, and 
the underline. To conform with loader requirements, 

underline is left alone. underline is translated to underline is translated to '#' 

in external names. in external names. 

A serious problem faced by C users in non-UNIX environments is calling non-C library 
routines. In general, these are likely to conform to fortran specifications. The basic incompa¬ 
tibilities arise from the fortran view that subroutines arguments are passed by address, not 
value, and that passing an array name is the same as passing the first element of the array. 

The operating system is Scalar integers and doubles It is not now possible to 

written in C, and communi- can be passed to and from communicate with standard 

cation with it is easy. It is fortran. Vectors can be OS programs without editing 

not possible to communi- passed from C to FORTRAN the assembly code produced 

cate with fortran, since by passing an argument of by the compiler. The IBM 

the fortran compiler does p[0], where p is an integer calling sequence for C 

not actually produce in- pointer to the beginning of routines is being changed; 

dependent object programs. the vector. Passing an array when the new sequence is 

from fortran to C requires installed, the rules for 

use of the xnargs routine FORTRAN-C interchange will 

^ described in section 8. be similar to the rules on 

GCOS. 

4. BASIC CHARACTER STREAM ROUTINES 

These routines transfer streams of characters in and out of C programs. Interpretation of 
the characters is left to the user. Facilities for interpreting numerical strings are presented in 
section 5; and routines to transfer binary data to and from files or devices are discussed in sec¬ 
tion 6. In the following routine descriptions, the optional argument fd represents a file- 
descriptor; if not present, it is taken to be 0 for input and 1 for output. When your program 
starts, remember that these are associated with the “standard” input and output files. 




COPEN ( filename , type) 

Copen initiates activity on a file; if necessary it will create the file too. Up to 10 files may be 
open at one time. When called as described here, copen returns a filedescriptor for a character 
stream file. Values less than zero returned by copen indicate an error trying to open the file. 
Other calls to copen are described in sections 6 and 7. 

Arguments : 

Filename: a string representing a file name, according to the local operating system conventions. 
All accept a string of letters and digits as a legal file name, although leading digits are not 
recommended on GCOS. 

Type: a character ‘r, ‘w’, or ‘a’ meaning read, write, or append. Note that the type is a single 
character, whereas the file name must be a string. 

On os/370 opening files 
with the ‘a’ option (to ap¬ 
pend to the end) is not yet 
implemented. 


CGETC (fd ) 

Cgetc returns the next character from the input unit associated with fd On end of file cgetc re¬ 
turns \0. To signal end of file from the teletype, type the special symbol appropriate to the 
given operating system: 

EOT (control-D) FS (control-\) /* 


the given output unit. Cputc returns as its value the character 


CPUTC (ch ,fd) 

Cputc writes a character onto 
written. 

Output for disk files is 
buffered in 512 character 
units, irrespective of new¬ 
lines; teletype output goes 
character by character 


If you write more than 511 
characters without a new- 
line, one will silently be in¬ 
serted. No actual writing of 
characters takes place until 
a newline is written. 


If you write more than 255 
characters without a new- 
line, one will silently be in¬ 
serted. No actual writing of 
characters takes place until 
a newline is written. Two 
consecutive newlines have a 
blank inserted between 
them. 


CCLOSE (fd) 

Activity on file fd is terminated and any output buffers are emptied. You usually don’t have to 
call cclose;cexit will do it for you on all open files. However, to write some data on a file and 
then read it back in, the correct sequence is: 

All Systems 


fd = copen (“file”, ‘w’); 
write on fd ... 
cclose (fd); 

fd = copen (“file”, ‘r’); 
read from fd ... 
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CFLUSH (fn) 


To get buffer flushing, but rei 
Normally, output intended 
for the teletype is not 
buffered and this call is not 
needed. 


i the ability to write more on the 
All output is buffered into 
lines, and calling cflush 
causes a newline to be in¬ 
serted. 


file, you may call this routine. 
All output is buffered into 
lines, and calling cflush 
causes a newline to be in¬ 
serted. 


CEXIT ([encode]) 


Cexit closes all files and then terminates execution. If a non-zero argument is given, this is as 
sumed to be an error indication or other returned value to be signalled to the operating system 


Cexit must be called expli¬ 
citly; a return from the 
main program is not ade¬ 
quate. 


An appropriate error indica¬ 
tion is the octal value of two 
BCD characters marking a 
Geos abort code. 


An appropriate error indica¬ 
tion is either 4, 8, 12, or 16 
to suggest the usual os lev¬ 
els of errors. 


CEOF (fd) 

Ceof returns nonzero when end of file has been reached on input unit fd. 


GETCHAR () 

Getchar is a special case of cgetc; it reads one character from the standard input unit. Getchar () 
is defined as cgetc (cin); it should not have an argument. 

PUTCHAR(ch) 

Putchar (ch) is the same as cputc (ch, cout); it writes one character on the standard output. 

GETS (s) 

Gets reads everything up to the next newline into the string pointed to by s. If the last charac¬ 
ter read from this input unit was newline, then gets reads the next line, which on GCOS and IBM 
corresponds exactly to a logical record. The terminating newline is replaced by ‘\0’. The value 
of gets is s, or 0 if end of file. 

Gets removes trailing blanks 
from the input line, to com¬ 
pensate for their insertion 
by the operating system 
when it is padding records 
to fixed length. 


P UTS (s) 

Copies the string s onto the standard output unit. The terminating ‘\0’ is replaced by a newline 
character. The value of puts is s. 

UNGETC (ch , fd ) 

Ungetc pushes back its character argument to the unit fd, which must be open for input. After 
ungetc Ca’, fd); ungetc Cb’, fd); the next two characters to be read from Jd will be ‘b’ and then 
‘a’. Up to 100 characters may be pushed back on each file. This subroutine permits a program 
to read past the end of its input, and then restore it for the next routine to read. It is impossi¬ 
ble to change an external file with ungetc; its purpose is only for internal communications, most 
particularly scanf, which is described in section 5. Note that scanf actually requires only one 









- 7 - 


character of “unget” capability; thus it is possible that future implementors may change the 
specification of the ungetc routine. 

5. HIGH-LEVEL CHARACTER STREAM ROUTINES 

These two routines, print/for output and scan/ for input, permit simple translation to and 
from character representations of numerical quantities. They also allow generation or interpre¬ 
tation of formatted lines. 

PRIN TF ([fd, ] control-string, argl, arg2, ...) 

PR INTF ([—1, output-string, ] control-string, argl, arg2, ...) 

Print/ converts, formats, and prints its arguments under control of the control string. The con¬ 
trol string contains two types of objects: plain characters, which are simply copied to the output 
stream, and conversion specifications, each of which causes conversion and printing of the 
next successive argument to print/. 

Each conversion specification is introduced by the character *%’. Following the ‘%\ there may 
be: 

— an optional minus sign ’ which specifies left adjustment of the converted argu¬ 
ment in the indicated field; 

— an optional digit string specifying a minimum field width; if the converted argu¬ 
ment has fewer characters than the field width it will be padded on the left (or 
right, if the left adjustment indicator has been given) to make up the field width; 
the padding character is blank normally and zero if the field width was specified 
with a leading zdro (note that this does not imply an octal field width); 

— anN)ptional period V which serves to separate the field width from the next digit 
string; 

— an optional digit string (the precision) which specifies the maximum number of 
characters to be printed from a string, or the number of digits to be printed to the 
right of the decimal point of a floating or double number. 

— an optional length modifier T which indicates that the corresponding data item is 
a long rather than an int. 

— a character which indicates the type of conversion to be applied. 

The conversion characters and their meanings are: 

d The argument is converted to decimal notation, 
o The argument is converted to octal notation, 

x The argument is converted to hexadecimal notation. 

u The argument is converted to unsigned decimal notation. This is only imple¬ 
mented (or useful) on UNIX, 
c The argument is taken to be a single character. 

s The argument is taken to be a string and characters from the string are printed 

until a null character is reached or until the number of characters indicated by the 

precision specification is exhausted. 

e The argument is taken to be a float or double and converted to decimal notation 
of the form [-] m.nnnnnnE [-]xx where the length of the string of n’s is specified by 
the precision. The default precision is 6 and the maximum is 22. 
f The argument is taken to be a float or double and converted to decimal notation 
of the form [-Jmmm.nnnnn where the length of the string of n's is specified by the 




precision. The default precision is 6 and the maximum is 22. Note that the preci¬ 
sion does not determine the number of significant digits printed in f format. 

If no recognizable conversion character appears after the *%’, that character is printed; thus ‘%’ 
may be printed by use of the string “%%”. 

As an example of printf, the following program fragment 

int i, j; float x; char *s; 

i = 35; j=2; x= 1-Z22; s = "ritchie 

printf (“%od %f %s&f i, x, s); 

print/ (“%o, %4d or %-4d%5.5df i, j, j, s); 

would print 

35 1.732000 ritchie 
043, 2 or 2«A ritch 

If Jd is not specified, output is to unit cout. It is possible to direct output to a string in¬ 
stead of to a file. This is indicated by -1 as the first argument. The second argument should 
be a pointer to the string. Printf will put a terminating ‘\0’ onto the string. 

SCANF (l/d, ] control-string, argl, arg2, ....) 

SCANF (l—l, input-string, I control-string, argl, arg2, ....) 

Scan/ reads characters, interprets them according to a format, and stores the results in its argu¬ 
ments. It expects as arguments: 

1. An optional file-descriptor or input-string, indicating the source of the input characters; if 
omitted, file cin is used; 

2. A control string, described below; 

3. A set of arguments, each of which must be a pointer, indicating where the converted input 
should be stored. 

The control string usually contains conversion specifications, which are used to direct interpre¬ 
tation of input sequences. The control string may contain: 

1. Blanks, tabs or newlines, which are ignored. 

2. Ordinary characters (not %) which are expected to match the next non-space 
character of the input stream (where space characters are defined as blank, tab or 
newline). 

3. Conversion specifications, consisting of the character %, an optional assignment 
suppressing character *, an optional numerical maximum field width, and a conver¬ 
sion character. 

A conversion specification is used to direct the conversion of the next input field; the result is 
placed in the variable pointed to by the corresponding argument, unless assignment suppres¬ 
sion was indicated by the * character. An input field is defined as a string of non-space charac¬ 
ters; it extends either to the next space character or until the field width, if specified, is ex¬ 
hausted. 

The conversion character indicates the interpretation of the input field; the correspond¬ 
ing pointer argument must usually be of a restricted type. Pointers, rather than variable 
names, are required by the “cafi-by-value” semantics of the C language. The following conver¬ 
sion characters are legal: 

% indicates that a single % character is expected in the input stream at this point; 
no assignment is done. 

d indicates that a decimal integer is expected in the input stream; the correspond¬ 
ing argument should be an integer pointer. 
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o indicates that an octal integer is expected in the input stream; the corresponding 
argument should be a integer pointer. 

x indicates that a hexadecimal integer is expected in the input stream; the 
corresponding argument should be an integer pointer. 

s indicates that a character string is expected; the corresponding argument should 
be a character pointer pointing to an array of characters large enough to accept the 
string and a terminating ‘\Q\ which will be added. The input field is terminated by 
a space character or a newline. 

c indicates that a single character is expected; the corresponding argument should 
be a character pointer; the next input character is placed at the indicated spot. The 
normal skip over space characters is suppressed in this case; to read the next non¬ 
space character, try %ls. 

e or f indicates that a floating point number is expected in the input stream; the next 
field is converted accordingly and stored through the corresponding argument, 
which should be a pointer to a float. The input format for floats is a string of 
numbers possibly containing a decimal point, followed by an optional exponent field 
containing an E or e followed by a possibly signed integer. 

1 indicates a string not to be delimited by space characters. The left bracket is fol¬ 
lowed by a set of characters and a right bracket; the characters between the brack¬ 
ets define a set of characters making up the string. If the first character is not 
circumflex ('), the input field is all characters until the first character not in the set 
between the brackets; if the first character after the left bracket is ", the input field 
is all characters until the first character which is in the remaining set of characters 
between the brackets. The corresponding argument must point to a character array. 

The conversion characters d, o and x may be preceded by / to indicate that a pointer to 
long rather than ini is expected. Similarly, the conversion characters e or / may be preceded by 
/ to indicate that a pointer to double rather than float is in the argument list. The character h 
will function similarly in the future to indicate short data items. 

For example, the call 

int i; float x; char name[50]; 
scanf ( “%d%f%s”, &i, &x, name); 

with the input line 

25 54.32E—1 thompson 

will assign to / the value 25, x the value 5.432, and name will contain “thompson\0”. Or, 
int i; float x; char name[50]; 
scan/C‘^°^*d^[1234567890r, &i, &x, name); 

56789 0123 56a 72 

will assign 56 to i, 789.0 to x, skip “0123”, and place the string “56\0” in name. The next call 
to cgetc will return ‘a’. 

Scanf returns as its value the number of successfully matched and assigned input items. 
This can be used to decide how many input items were found. On end of file, -1 is returned; 
note that this is different from 0, which means that the next input character does not match 
what you called for in the control string. Scanf if given a first argument of -1, will scan a 
string in memory given as the second argument. For example, if you want to read up to four 
numbers from an input line and find out how many there were, you could try 
int a[4] amax; 
char lineflOOj; 

amax = scanf (—1, gets(line), “ %d%d%d%d", &a[0], &a[l], &a[2], &a[3]); 


of f /V s ~\ 

/o'- 3 
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6. BINARY STREAM ROUTINES 

These routines write binary data, not translated to printable characters. They are normal¬ 
ly efficient but do not produce files that can be printed or easily interpreted. No special infor¬ 
mation is added to the records and thus they can be handled by other programming systems if 
you make the departure from portability required to tell the other system how big a C item (in¬ 
teger, float, structure, etc.) really is in machine units. 

All GCOS records comprising 
a number of characters not 
divisible by 4 are extended 
to whole machine words; 
but the padding is carefully 
removed when the records 
, ‘ are read. 

" 

COPEN (name, direction, “i”) 


When copen is called with a third argument as above, a binary stream filedescriptor is returned. 
Such a file descriptor is required for the remaining subroutines in this section, and may not be 
used with the routines in the preceding two sections. The first two arguments operate exactly 
as described in section 3; further details are given in section 7. 


An ordinary file descriptor 
may be used for binary I-O, 
but binary and character 1-0 
may not be mixed unless 
cfiush is called at each 
switch to binary I-O. The 
third argument to copen is 
ignored. 

CWRITE (ptr, $izeof(*ptr), nit 


The third argument of “i” is 
required. Programs which 
write and read mixed mode 
data files will be supported 
on gcos someday, but don’t 
hold your breath. 


*.fd) 


An ordinary file descriptor 
may be used for binary I-O, 
but record lengths are limit¬ 
ed to 255 bytes. Do not 
mix character and binary I- 
O except at record boun¬ 
daries. 


Cwrite writes niterns of data beginning at ptr on file fd. Cwrite writes blocks of binary informa¬ 
tion, not translated to printable form, on a file. It is intended for machine-oriented bulk 
storage of intermediate data. Any kind of data may be written with this command, but only 
the corresponding cread should be expected to make any sense of it on return. The first argu¬ 
ment is a pointer to the beginning of a vector of any kind of data. The second argument tells 
cwrite how big the items are. The third argument specifies the number of the items to be writ¬ 
ten; the fourth indicates where. 


On GCOS, cwrite may only be 
used on files opened with 
the “i” option. 

\A 

CREAD (ptr, sizeoff *ptrj, ni terns, fd) 




Cread reads up to nitems of data from file fd into a buffer beginning at ptr. Cread returns the 
number of items read. 


mm 


r •> 




On UNIX, where there are 
no records, the returned 
number of items will be 
equal to the number re¬ 
quested by nitems except for 
reading certain devices (e.g. 
the teletype or magnetic 
tape) or reading the final 
bytes of a disk file. 


On GCOS, this is the number 
of items actually contained 
in the next logical record. 
Cread may only be used on 
files opened with the “i” 
option. 


On OS/370, this is the 
number of items actually 
contained in the next logical 
record. 


Again, the second argument indicates the size of the data items being read. 


CCLOSE (fd) 

The same description applies as for character-stream files. 


7. OTHER PORTABLE ROUTINES 


REW (fd) 

Rewinds unit fd. Buffers are emptied properly and the file is left open. 

SYSTEM (string) 

The given string is executed as if it were typed at the terminal. 

String must be 80 characters The string should be in 

or less. This routine should upper case. This routine 

not be used in batch opera- will not work in batch, 
tion. 


NARGS () ? 

A subroutine can call this function to try to find out how many arguments it was called with. 
Normally, nargsO returns 
the number of arguments 
plus 3 for every float or dou¬ 
ble argument and plus one 
for every long argument. If 
the new UNIX feature of 
separated instruction and 
data space areas is used, 
nargsO doesn’t work at all. 

CALLOC (n, sizeof(object)) 

Calloc returns a pointer to new storage, allocated in space obtained from the operating system. 
The space obtained is well enough aligned for any use, i.e. for a double-precision number. 
Enough space to store n objects of the size indicated by the second argument is provided. The 
sizeof is executed at compile time; it is not in the library. Failure to obtain space is variously 
indicated: 

Returns -1. GC abort. 804 or 80A abend. 

CFREE (ptr, n, sizeof(*ptr)) 

Cfree returns to the operating system memory starting at ptr and extending for n units of the 


The form of the call is nargs 
(ndecl) where ndecl is the 
number of declared argu¬ 
ments. 



size given by the third argument. The space should have been obtained through calloc. 

On UNIX you can only re¬ 
turn the exact amount of 
space obtained by calloc; the 
second and third arguments 
are ignored. 

FTOA (floating-number, char-string, precision, format) 

Ftoa (floating to ascii conversion) converts floating point numbers to character strings. The 
format argument should be either T or ‘e’; ‘e’ is default. See the explanation of print/ in sec¬ 
tion 5 for a description of the result. 

Ftoa is not available on 

OS/370. 


A TOF (char-string) 

Returns a floating value equal to the value of the ascii character string argument, interpreted 
as a decimal floating point number. 

Atof is not available on 

OS/370. 


TMPNAM (str) 

This routine places in the character array expected as its argument a string which is legal to use 
as a file name and which is guaranteed to be unique among all jobs executing on the computer 
at the same time. It is thus appropriate for use as a temporary file name, although the user 
may wish to move it into an appropriate directory. The value of the function is the address of 
the stringy ' , 

,^v\v\v\, o Not yet implemented on 

ABORT (code) 

Causes your program to terminate abnormally, which typically results in a dump by the operat¬ 
ing system. 

INTSS () 

This routine tells you whether you are running in foreground or 
The definition of “fore¬ 
ground” is that the standard 
input is the terminal. 

WDLENG () 

This deliberately different routine distinguishes the local system. 

Returns 16. Returns 36. Returns 32. 

C users should be aware that the preprocessor normally provides a defined symbol suitable for 
distinguishing the local system; thus on UNIX the symbol unix and on GCOS the name geos is 
defined before starting to compile your program. 


background. 

The name may also be 
spelled intso (). 



8. FEATURES RESTRICTED TO ONE OPERATING SYSTEM 

You can read this section even if you intend to write portable programs, but I don’t know 
why you would want to. It describes routines tied to one of the three environments where C 
operates. These include both generally useful routines which we do not know how to define 
elegantly and efficiently for all operating systems, and also routines which no one would want 
to execute except on the specific system for which they are defined. Some of the routines in 
this section are of extremely specialized interest. The procedures copen and cexit, which have 
been described earlier in a restricted way, are defined fully in this section. 

8U. UNIX SPECIFIC ROUTINES 

Since most of the UNIX operating system and its software are written in C, a great many 
more library routines are available here for system-specific operations. Users should consult 
the UNIX Programmer’s Manual for details[2], 

8G. GCOS SPECIFIC ROUTINES 

On gcos, where C has been used for systems programming tasks, there is a supply of 
subroutines to permit access to operating system control points. Furthermore, the variety of 
file types on GCOS requires additional flexibility in the 1-0 routines to cater to those not 
satisfied with default file handling. 

COPEN (filename, type, options) 

The function copen has a number of other possible option arguments to produce very specific 
results in terms of the gcos file system. 

In analyzing the filename, file creation and accessing use the bfor library jfilac 
subroutine; the overall operation follows the computation center’s standard conventions: 

First, throw away any permissions or alternate names, (as defined by the standard gcos con¬ 
ventions; since the second argument specifies whether reading or writing is required, the per¬ 
missions are redundant). Then, if filename does not contain a slash: 

a. A file already accessed with this name is searched for in the aft. 

b. If this is unsuccessful, an attempt is made to access a permanent file with the 
specified name in the user’s catalog. 

c. If this fails and write or append operation was requested, a temporary file is creat¬ 
ed. 

If filename contains a slash: 

a. An attempt is made to access a permanent file by this name. 

b. If this is unsuccessful and write or append operation was requested, a permanent 
file is created. 

Files with the same name from different catalogs may be open simultaneously; this is done by 
using funny AFT names (“0.” to “9.”) for permanent files. When a file is closed, cclose 
deaccesses permanent files; thus the user never sees the funny aliases. 

In batch, the treatment of permanent files is similar to their treatment in time-sharing. 
When accessed, they are given funny filecodes rather than funny aft names. Temporary files 
in batch are created as needed for filenames not containing a 7’; note that such files disappear 
at the end of the batch activity and are only useful if they are written, closed, and read within 
one activity. For example, the command line prog >junk in TSS writes the output onto a tem¬ 
porary file junk which can later be picked up from the AFT and read; but in batch, if junk is not 
in your catalog you have just thrown away the output. (See below to find out how to provide a 
command line in batch.) Any file name beginning with refers to an externally defined 
filecode; the second and third characters of the name define the filecode. When writing, tem¬ 
porary files are created for non-existent filecodes. Since these do not have save disposition, 
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however, multi-activity jobs should use permanent files or filecodes defined by $ file control 
cards to pass information from one activity to the next. At the moment, parameters on $ FFILE 
control cards are ignored. 

The options argument is a string made up of a combination of the following characters 
(other characters are ignored), which usually specifies a very GCOS-specific option for file 
specification: 

t: assign to teletype. In time-sharing, this file is assigned to the user’s terminal; the 
filename is ignored. In batch, lines written on the file have printer slew added. 

2: indicates that this is a standard system format BCD file. This option is not necessary 
on a file being read, but is the only way to write a BCD file. Normally such files are 
written in media code 2; if the slew option ‘s’ is present they are written with code 
3. Media code 2 files are padded to 80 characters to be a card image. This can be 
suppressed by using media code 0 (see below). 

s: printer slew is present or is to be generated. This option is only relevant for mode 
2 files; and it should be omitted if no slew is desired or present. Unfortunately, 
GEFRC will not recognize the presence of slew on an input file, so that this option is 
required to read a BCD file with slew (media code 3). Note that qed writes BCD files 
without slew but Fortran usually writes them with slew. 

i: binary stream file. This file is defined to be a stream of machine-oriented rather 
than character-oriented quantities. See section 6 for discussion of binary stream 
files. 

3: media code 3 file, i.e. BCD with printer slew. This is equivalent to "2s". 

0: media code 2 file, i.e. BCD, no slew, not padded to a card image. 

d: discuss file accessing errors at terminal, rather than just returning an error code. 
This permits the user to correct file opening errors at run time. 

I: leave this file in aft after it is closed; normally permanent files not originally 
present are deleted. 

f: full aft name given; this suppresses the normal creation of C altnames for files ac¬ 
cessed by C. If you don’t understand this, you don’t need it. 

When copen returns a negative value, there has been an error trying to open the file. The 
specific negative number is usually that provided by the system file-access routine. If you 
specify the d option to copen , a message will be typed on the terminal, and you will have a 
chance to adjust the open request. Note in batch that the abort code MZ (not on the green 
cards) refers to an error in the Fortran file-accessing package. 

There is one unusual filecode in batch operation: the command line, if required by the 
program, is expected on filecode cz. This filecode is created by the Jsh program if used to 
spawn batch jobs; alternatively, you may provide a $ data cz card in your deck. This permits, 
for example, redirection of the standard input and output in batch. 

CGETl (buff, len, fd) 

Cgeti places the next record from unit fd into buff, and returns the number of integers read; 0 
on eof. The unit fd must have been opened with the “i” option and may not be addressed by 
cgetc calls or by ungetc. The second argument indicates the length of your input buffer, which 
should be large enough for the records being read. 

CPUTI (buff len, fd) 

Cputi writes len words from buff onto unit fd as a single GCOS record. The file fd must have 
been opened with the “i” option, and cputc must not be used on this file. 








- 15 - 


BACK dfd]) 

The file J'd is backspaced one logical record. Since copen rewinds files as they are opened, these 
routines need not normally be used. The direction of the file (input or output) is retained after 
reverse motion. See the gefrc manual [3] or experts to understand such operations as back¬ 
spacing the teletype. The default file descriptor is cin 

XNARGS (ptrs) 

The addresses of the arguments to the calling program are placed in the array of pointers ptrs. 
The function returns the number of arguments. It does not matter how many arguments are 
declared; xnargs depends only on the actual invocation. This routine permits a C program be¬ 
ing called by fortran to pick up the positions of arrays being passed as arguments. 

DRLDRL (number, argl, arg2, ... ) 

This call causes the execution of the instruction sequence 
drl number 
argl 
arg2 

with the A and Q registers taken from the external integers .a.reg and .q.reg and restored to 
these cells after the derail returns. For example, drldrl (5) (derail return) exits without closing 
files, etc. If you don’t understand this routine, you don’t need it. 

MMEMME (number, argl, arg2, ... ) 

This routine is the same as drldrl except that it executes the batch system call instruction in¬ 
stead of the time-sharing instruction. 

81. IBM SPECIFIC ROUTINES 

This section describes routines which only apply to the IBM os/370 C system. It is likely 
that as C usage on this system expands, additional routines will be added. 

COPEN (name, direction, options) 

The name given is only taken as a file name in TSO. In batch os, dynamic file accessing is im¬ 
possible, and the name is taken as a ddname. The only legal format for a ddname (and thus 
for a batch name argument to copen) is "ft??f001" where the question marks are replaced by di¬ 
gits. This name must be defined on a dd job control language statement. Such names are 
treated similarly in TSO (the data set must have been allocated to this name) but any other 
name is also legal in TSO, and is allocated by the run-time library. The format of new output 
files is TSO .text style. As on GCOS, the IBM version of copen takes an optional third argument to 
specify some details of file handling. In particular it is occasionally necessary to override the 
default operation of placing a blank at the head of each output line being sent to a printer. 
This suppresses carriage control so that C programs written without reference to it work 
correctly. The possible characters (given either as a single character argument, or as a member 
of a string) are 

e "edit mode": on output, changes lower case to upper case and tab characters into blanks, 
b Places a blank at the beginning of each output line (for carriage control on a printer), 
n Does not place a blank at the beginning of each output line, even if this stream is headed 
for a printer. 



GENREG (regno, ndecl) 

Genreg returns the value register regno had on entry to the calling function; ndecl is the 
number of declared arguments in the calling function. 

9, CC - THE C COMPILER COMMAND 

This section describes the commands to compile and load C programs on the three 
different operating systems. On all systems, C is designed to be used with input files of vari¬ 
able line length and upper/lower case ascii character set. Files should not be line numbered. 
Any standard ascii terminal suffices to enter a C program, but a terminal restricted to upper 
case or the PL/I character set will be almost impossible to use with C. 

9U. UNIX COMPILING COMMANDS 

This description of the C compiling command on UNIX is taken from the UNIX 
Programmer’s Manual (© Bell Laboratories 1972-1975). Reprinted by permission. 

The format of the C compiling command on UNIX is 
cc [ -c ] [ -p ] [ -f ] [ -O ] [ -S ] [ -P ] file ... 

The UNIX C compiler accepts three types of arguments: source programs, compiler op¬ 
tions, and other loader-directed information. 

Arguments whose names end with ‘.c’ are taken to be C source programs; they are com¬ 
piled, and each object program is left on the file whose name is that of the source with ‘.o’ 
substituted for ‘.c’. The ‘.o’ file is normally deleted, however, if a single C program is compiled 
and loaded all at one go. 

The following compiler option flags are interpreted by cc: 

—c Suppress the loading phase of the compilation, and force an object file to be produced 
even if only one program is compiled. 

-p Arrange for the compiler to produce code which counts the number of times each routine 
is called; also, if loading takes place, replace the standard startup routine by one which 
automatically creates the data file of profiling information during execution of the object 
program. An execution profile can then be generated by use of the UNIX prof command, 
-f In systems without hardware floating-point, use a version of the C compiler which han¬ 
dles floating-point constants and loads the object program with the floating-point inter¬ 
preter. Do not use if the hardware is present. 

-O Invoke an object-code optimizer. 

-S Compile the named C programs, and leave the assembler-language output on correspond¬ 
ing files suffixed ‘.s’. 

-P Run only the macro preprocessor on the named C programs, and leave the output on 
corresponding files suffixed ‘.i’. 

Other arguments are taken to be either loader flag arguments, or C-compatible object pro¬ 
grams, typically produced by an earlier cc run, or perhaps libraries of C-compatible routines. 
These programs, together with the results of any compilations specified, are loaded (in the ord¬ 
er given) to produce an executable program with name a.out. 



- 17 - 


9G. THE GCOS C COMPILER COMMAND 

The commmand Jcc compiles and loads C programs. To compile x.c, y.c and z.c, placing 
the result on a permanent random library clib, type 

Jcc x.c y.c z.c r=/clib 

or to run a.c with clib and put the H* (executable version) on prog, type 
Jcc a.c clib x=prog 

The command line arguments are separated by blanks. They are divided into three ca¬ 
tegories. Unlike the cc command on UNIX, the syntax of a file name is never meaningful; 
source programs need not end in ‘.c\ for example. The types of arguments are: 

1. random libraries: saved for loading. 

2. sequential files: sent to the C compiler. 

3. strings with '=’ in them: command options. 

Command options are (the text in parentheses is optional): 

1. r(anlib)=name: merge file for compiler output; also used as a library for loading. 

2. h(star)=name or just =name: time-sharing H* file to be created. The file can be run 
directly with the system command loader or the go command. If name is omitted, the de¬ 
fault is .program. 

3. x(ecute)=name: do an h=name and then run the program. 

4. f(ortran,orty,ortrex)=name or g(map)=name: program written in Fortran or assembler to 
be included in library or H* file. 

5. b(atchhstar)=name: batch H* file to be created. Such a file may not be executed in 
time-sharing. 

6. o(ptions)=name: use bfor options on file name. 

7. m(ap)=name: put assembly listings and load map on file name. 

8. u(se)=name: program references needed for loading. 

9. e(ntry)=name: replace normal starting point with name. 

10. k(eep)=name: place the GMAP translation of the next source program being compiled 
on file name, which will be made a permanent file in your catalog. 

11. d(ebug)=no: suppress the compilation of symbol tables and the loading of the debugger 
(see section 12). 

12. l(imits)=string: make a $ limits card for bfor. String should be something like “,26k”. 

If you give no options on your command line, but only filenames, the default is 
r = .library. Be careful with the order of libraries and options on the command line; they are 
used in the sequence given, and an options file, if any, is inserted at the place requested. Note 
that no default options file is used, unlike bfor. Loading involves the library cc/c.t.lib preceded, 
in batch only, by cc/c.b.lib; the normal entry point is . (the GCOS standard). The bfor li¬ 

braries are also used. 

91. IBM COMPILING COMMANDS 

Standard TSO command lists have been defined for C compilation and loading. They are 
installed in the standard system procedure library. Supposing that the program is on a file 
prog, text, to compile, say 

cc prog 

and to compile and execute say 




ccg prog 


The C run-time library is stored on the library sys3.clib for linking or loading. C requires the 
fortran runtime library syshfortlib as well. On tso it is not now possible to compile more 
than one source program at a time. The dialog to compile and run the programs pl.text, 
p2.text, and p3.text would appear as follows: 

READY 
cc pi 
READY 
cc p2 
READY 
CC p3 
READY 

loadgo (pl.obj p2.obj p3.obj) lib('sys3.clib', 'sysl.fortlib') 

To use the C compiler on tso, the user should specify a 250K region at logon. 

In batch os/370 it is not possible to run the C compiler, because the preprocessor com¬ 
mand “include” implies dynamic file attaching, which is only supported in time-sharing under 
os/370. The IBM C compiler is still under development, and it is likely that some of the restric¬ 
tions in this paper will be removed. In particular, floating point and the associated library 
routines will be included, and the calling sequence will be altered for easier compatibility with 
other programming languages. 


10. GCOS PSEUDO-SHELL 

The GCOS program ,/sh provides the syntax of the UNIX command language on the GCOS 
operating system. It may be used conveniently with either C or BFOR programs. To simplify 
the distinction between batch and time-sharing, it handles object programs most conveniently 
in the form of random libraries. It will generate, as required, batch or time-sharing versions of 
such programs and execute them. 

For example, suppose that the simple file copy routine discussed in section 1 is stored on 
random library prog.r by a command such as 
Jcc prog r=/prog.r 

or equivalent. In that case, the following sequence would submit first a batch and then a 
time-sharing job to perform file copies: 

SYSTEM ?./sh 

*** ? = prog.r <data >newdata & 

= prog.r <oldlist >newlist 

Jsh is an imitation of the UNIX shell for GCOS. For example, to release all files with 
names ending in “.g”, type Jsh rele *.g. To make an archive file of all files with names sl.c, 
s2.c, s3.c, etc., type Jsh Jarch c arfile s?.c To execute commands on file junk, type Jsh <junk. 
To load and run the random library prog.r, type Jsh prog.r. To spawn a batch job to execute 
the same program, type Jsh prog.r & 

The input line is divided by spaces, semicolons, and commas. Each piece is examined for 
the characters ?, [, and *; if it contains one of them, it is replaced by the permanent quick- 
access file names it matches. The UNIX rules are used: ? matches any single character; * 
matches anything; [chars] matches any of the characters in chars; [a-d] matches any character 
between a and d inclusive. Thus, a? is replaced by all two-letter file names beginning with a; 
a* is replaced by all file names beginning with a; *.g is replaced by all file names ending in .g; 
a[125-8] is replaced by any of the file names al, a2, a5, a6, a7, a8 which exist, and so on. 
Backslash may be used to escape the special characters; for example, 


Jsh bfor run\*\* libr=mylib,use =main 

If all you want is a list of names, you can use Jsh Jnull pattern to get a list of all file names 
matching pattern. 

The result is reassembled into a GCOS command line, printed and executed. You need 
not worry about the details of command reassembly; the shell follows the command loader’s 
requirements. These are: for the commands list, rele, purge or remo the first two items are 
separated by blank and the rest by semicolon; for the commands bfor, edit, yrun or jrun the first 
three items are separated by blank and the rest by semicolon; for the command get the first 
two items are separated by blank and the remainder by comma; for command filsys the first 
three items are separated by blank and the rest by comma; otherwise all items are separated by 
blanks. If the assembled line exceeds 80 characters it is not executed due to a deficiency in 
the command loader. 

If the first item on the line to be executed is a random library, it is loaded and then exe¬ 
cuted. The loading is done by bfor; the libraries used are each input argument, until the first 

non-library, followed by cc/c.t.lib, and bfor/syslib. Use commands are given for .and main. 

This suffices for most C and bfor jobs. The output is put on temporary file ,pg and executed 
with go. Remaining (i.e. non-library) command line arguments are fed to the resulting pro¬ 
gram. If the first item on the command line is a random library, and the last is ‘&’ or fol¬ 
lowed by a string in parentheses, a batch job is spawned to run the program. The batch job 
uses cc/c.b.lib in addition to cc/c.t.lib, and bfor/batchlib in place of bfor/syslib, and the command 
line is provided on filecode cz. If a string in parentheses followed the ‘&\ it is used as an op¬ 
tion string to jrun; thus the line 

prog.r < input > output &(sl) 

runs prog.r in batch with diverted input and output and at service grade 1. For the benefit of 
FORTRAN users, the shell recognizes such constructions as 5<file or 6>file and causes the file 
to be accessed with altname or filecode corresponding to the given number. This permits for¬ 
tran programs running with the shell to divert their output. Any number, of course, may be 
used with the shell, but gcos fortran only recognizes filecodes from 1 to 39. 

If Jsh has no arguments, it reads lines and executes each in turn. Since it is a C program, 
it can thus be used to execute a file by Jsh <filename. Alternatively, it can be used in front of 
the GCOS command loader as a filter by just saying Jsh. In this case, you type lines which are 
translated and then executed. To get out of the pseudo-shell, type a blank line. 

If you have more than 150 quick-access files, only the 150 most recently created are used 
with *, ? and []. aft names are not used; thus you may have trouble with temporary files or 
alternate names, neither of which are known to the shell. Because of the escapes, \ must 
sometimes be input as \\. The shell accepts command files with arguments as on UNIX. 
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11. MEASUREMENT FACILITIES 

In general, these are derived from the operating system, and thus vary from machine to 
machine. 


The standard UNIX profiler 
can be invoked by compil¬ 
ing your program with the 
—p flag of the compiler, e.g. 
"cc -p file.c". After run¬ 
ning the resulting program, 
the prof(l) command will in¬ 
dicate the amount of time 
spent in each subroutine. 


If you load the library 
(.Ihist.r, with your programs 
allhe end of the run a table 
is printed showing the 
number of times every C 
subroutine was called. If 
you want to histogram parts 
of your program, you may 
call the entry .phist at any 
time; it will print the 
current counts and reset 
them to zero. 


There are no specifically C- 
oriented measurement facil¬ 
ities on the OS system. The 
GCOS histogrammer is not 
yet installed. 


12. DEBUGGING FACILITIES 


On GCOS and UNIX there are symbolic post-mortem dump facilities for C programs. The 
UNIX debugger, written by D. M. Ritchie, is only outlined below; more detail is available in the 
UNIX Programmer’s Manual. Errors in a running C program cause a brief message to be typed, 
followed by the option of entering the debugger. 


When a C program faults, 
the core image is written to 
a file and the system returns 
to command level. The de¬ 
bugger can be entered by 
typing cdb (with optional ar¬ 
guments giving the names 
of the load module and core 
image files if non-standard). 


The debugger is entered au¬ 
tomatically after a fault; or, 
by calling x dbugO it can be 
entered deliberately. In 
batch, the debugger is en¬ 
tered on fault, prints a sym¬ 
bolic dump, and exits. 


No C debugging facilities 
have been implemented yet 
on os/370. 



Interactive examination of the values of variables is possible; in general, each input line 
to the debugger specifies data to be printed as of the time of the fault. 


The debugger is used in¬ 
teractively. The first request 
should probably be $, which 
presents a list of executing 
subroutines and their argu¬ 
ments in octal. 


On entrance, the debugger 
asks you to choose between 
interactive examination or a 
full dump typed at the ter¬ 
minal or directed to a file. 
The first step if interaction 
is chosen is to present the 
list of active routines. 


The typical debugger command names a variable and asks for its value to be printed. 
The general format is 


subroutine.variable/format 

where format is one of the letters /', c, f d or 5 to specify integer, character, floating, double, or 
string printout. 
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If the format is omitted oc- If the format is omitted the 
tal integer is assumed. type of the variable is used 

to decide on the format. 

A command may also be given as 
number/format 

to examine a particular memory location by address. If the number begins with 0 it is taken as 
an octal address; otherwise it is a decimal address. 

The slash is required. The slash may be omitted. 

Non-word-aligned character 
data may be accessed with 
addresses of the form 
number.d where d is 0, 1, 2 
or 3 to select the bytes of a 
word. 

To find out the address of a variable, the format 
subroutine :variable= ( '' 

may be used. Other alternatives to / as a character after the variable name are " (equivalent to 
/s) and ' (equivalent to /c). 

An address or variable name may be followed by ,number which causes the indicated 
number of memory locations, beginning with the address or variable, to be printed. A format 
may follow. 

Not implemented: the size 
of arrays is known from the 
symbol tables and when an 
array is named its contents 
are all printed. 

On gcos there is a concept of “current routine”. The name of the subroutine need only 
be given when it changes, and the command name: is accepted to change it. The commands 
#up and #down move up and down the stack of active routines (“up” is towards the operating 
system, in the direction of returns; “down” is in the direction of calls). 

Not implemented: All of the variables of a 

subroutine names must be routine may be printed with 

given for each internal vari- the command #print. 
able. 

To exit from the debugger, type an end-of-file at it. 

On gcos the command 
#quit also exits. 

In general, the cost of the debugger is small. 




Since the debugger operates 
only on a post-mortem core 
image, there is no cost asso¬ 
ciated with the running pro¬ 
gram. 


The debugging routines re¬ 
quire about 2500 additional 
words of memory, plus the 
cost of the symbol tables, 
which run three words per 
variable. The d=no option 
of Jcc will suppress the de¬ 
bugger. 
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Appendix 1 

List of the C Library Routines 

Name Section 

ABORT (code) ........ 7 

ATOF (char-string) .. ..7 

BACK ([fd]) ..:.8G 

CALLOC (n, sizeof(object)) .7 

CCLOSE (fd) ..4 

CCLOSE (fd) .6 

CEOF (fd) .4 

CEXIT ([errcode]) .4 

CFLUSH (fn).4 

CFREE (ptr, n, sizeof(*ptr)).7 

CGETC ( fd )...4 

CGETI (buff, len, fd) . 8G 

COPEN (filename, type).4 

COPEN (filename, type, options) .8G 

COPEN (name, direction, options).81 

COPEN (name, direction, “i”) .6 

CPUTC (char, fd )...4 

CPUTI (buff, len, fd).8G 

CREAD (ptr, ptr+1, nitems, fd).6 

CWRITE (ptr, ptr+1, nitems, fd) .6 

DRLDRL (number, argl, arg2, ...) .8G 

FTOA (floating-number, char-string , precision , format) .7 

GENREG (regno, ndecl) .81 

GETCHAR 0 ...4 

GETS (s) ...4 

INTSS 0.7 

MMEMME (number, argl, arg2, ...) . 8G 

NARGS () .7 

PRINTF ([fd, ] control-string, argl, arg2, ...) ...5 

PUTCHAR (ch).....4 

PUTS (s).4 

REW (fd).7 

SCANF ([fd, ] control-string, argl, arg2, ....).5 

SYSTEM (string).7 

TMPNAM (str).7 

UNGETC (char , fd) .4 

WDLENG () .7 

XNARGS (ptrs). 8G 






